Attribute tables
Objects of all types can have many attributes or properties (the terms are interchangeable as used in this material) that are stored in the Repository. Developers can define attributes and then associate them with one or more object types. For SmartObjectss, these attributes are the same as the ADM2 properties that are defined in the property include files associated with each SmartObject super procedure class, such as smrtprop.i, cntnprop.i, and so forth. In the standard Version 9 ADM code, these include files actually define the attributes for each class, by building up a dynamic temp-table with a field for each attribute. If a SmartObject, such as a SmartDataBrowser, inherits from numerous classes, such as Smart, Visual, DataVis, and Browser, then its properties are the sum of all the properties defined for each of those classes, and its individual temp-table has a single record with a field for each of those properties.
This same mechanism is used for SmartObjects in Progress Dynamics. However, all the properties are defined in the Repository, so that the property include file definitions are not needed. This provides much improved flexibility, because you can add a new attribute to an object type by defining it in the Repository without having to recompile every SmartObject of that type. For compatibility with ADM2 applications that do not use Progress Dynamics, the property include files are still present and are still used to compile those non-Dynamics SmartObjects. However, SmartObjects in a Progress Dynamics application do not use the contents of the include files and instead build their temp-tables up from the records in the Repository.
Other kinds of objects can have attributes as well, in exactly the same way. DataFields, for example, which are the Repository’s representation of application database fields, also have attributes that are built up in the same way, even though they are not SmartObjects. Procedures and other kinds of objects recognized by the Repository also have attributes.
As shipped with the product, the Repository includes definitions for all the attributes used by the framework and its standard objects. These are defined in the ryc_attribute table, which has a record for each distinct attribute.
The ryc_attribute_group table facilitates the logical grouping of attributes to simplify their use. The primary use of this table is to make the presentation of the attributes to the user more effective and usable. There is an attribute_group record for each SmartObject class that defines attributes, such as Smart, Visual, DataVis, Query, etc. There is also a large attribute_group, called WidgetAttributes, with all of the field-level attributes that map to built-in 4GL widget attributes. There are other attribute groups as well. You can specify the attribute group in various framework tools to help you locate and organize attributes.
There is a record in the Repository for every attribute value of every object in the application. Some of these are defined at the object type level. These are default values for attributes for every object of a given type. Each individual object master can also have its own attribute values, and each instance of that object can have its own distinct values for attributes. The ryc_attribute_value table holds all of those values, one value per record. Each attribute value record is linked to either the class, the master object, or the instance for which it is defined. Any attribute value that is inherited by a master from one of its classes, or by an instance of a master, is only stored at the highest level, to reduce the data in the Repository and to facilitate an inheritance mechanism whereby any change to an attribute value at a higher level is automatically inherited by every object of that type that does not specifically override the default.
Figure 8–3 is an excerpt from the Repository database and shows the relationships between the attribute tables.
